home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
SGI Varsity Update 1998 August
/
SGI Varsity Update 1998 August.iso
/
docs6.4
/
relnotes
/
patchSG0002835
/
ch1.z
/
ch1
Wrap
Text File
|
1998-07-29
|
10KB
|
331 lines
- 1 -
1. _P_a_t_c_h__S_G_0_0_0_2_8_3_5__R_e_l_e_a_s_e__N_o_t_e
This release note describes patch SG0002835 to IRIX 6.4.
Patch SG0002835 replaces patches SG0002648, SG0002294 &
SG0001820.
1.1 _S_u_p_p_o_r_t_e_d__H_a_r_d_w_a_r_e__P_l_a_t_f_o_r_m_s
This patch contains bug fixes for IP27 & IP30 systems.
1.2 _S_u_p_p_o_r_t_e_d__S_o_f_t_w_a_r_e__P_l_a_t_f_o_r_m_s
This patch contains bug fixes for Specfs on a system running
IRIX 6.4. The software cannot be installed on other
configurations.
1.3 _B_u_g_s__F_i_x_e_d__b_y__P_a_t_c_h__S_G_0_0_0_2_8_3_5
This patch contains fixes for the following bugs in IRIX
6.4. Bug numbers from Silicon Graphics bug tracking system
are included for reference.
Patch 2835 fixes bugs:
+o 558439: A "memory deadlock" fix that was
introduced into Patch 2648 exposed another
problem. When the "sget" routine can not complete
the construction of a "local" snode because
another thread of control is also in the midst of
constructing the "common" snode for the same
device, the "sget" routine drops its locks, and
re-executes the loop. Previously the "sget"
routine would block on the global hash-chain lock,
but now that the memory deadlock problem has been
fixed, the global hash-chain lock is available,
and on single cpu systems, the "sget" routine may
loop indefinitely waiting on the completion of the
construction of the "common" snode, which will
never finish if the thread constructing the
"common" snode had been interrupted in a state
where it was not holding the global hash-chain
lock. The solution is to add a small "delay" just
before re-executing the "sget" loop, allowing the
interrupted thread constructing the "common" snode
to complete. The most common manifestation of
this problem happened on a single-cpu Octane
playing one track of an audio CD repeatedly while
having the "apanel" open. This produces an
interrupt-rich environment with two threads of
- 2 -
control (cdplayer & apanel) attempting to access
the same "special" device.
+o 560229: Some of the xlv commands are "sensitive"
to getting an error code returned to an fsync()
request. Fixing bug 543184 was when this started
to happen. Temporarily unfix just the fsync()
part of bug 543184, the rest will still work okay,
and this will allow things like xlv_make to work
again.
Replaces and rolls up:
Patch 2648, which fixes bugs:
+o 448776: A problem in the interaction of spec_get &
spec_inactive could result in a released vnode
being obtained by the spec_get routine. In this
case a panic in spec_open() occurred.
+o 508734: When a "get attribute" request provided a
zero buffer length a kernel panic could occur due
to missing "sanity" checking.
+o 518212: A problem in the interaction of spec_get &
spec_inactive could result in a released vnode
being obtained by the spec_get routine. In this
case a panic in spec_access() occurred.
+o 524849: A problem in the interaction of spec_get &
spec_inactive could result in a released vnode
being obtained by the spec_get routine. In this
case a panic in sget() occurred.
+o 531599: A problem in the interaction of spec_get &
spec_inactive could result in a released vnode
being obtained by the spec_get routine. In this
case a invalid snode caused the appearance that the
open counts had gone negative.
+o 538378: A problem in the interaction of spec_get &
spec_inactive could result in a released vnode
being obtained by the spec_get routine. In this
case a panic in slock() called out of spec_close()
occurred.
+o 543184: When a "special" file (such as a character
device) was served by nfs2 as an underlying file
system, "get attribute" requests that failed did
not pass the error up through specfs, causing
garbage output from "ls", or sometimes causing a
- 3 -
kernel panic.
Replaces and rolls up:
Patch 2294, which fixes bugs:
+o 448776: This fix addressed various panics in the
specfs code due to a VN_RELE race in the common
vnode handling.
+o 455371: This was a bug in the specfs file system
that caused a deadlock between specfs and the
console driver, often seen during shutdown.
+o 503045: This was a bug that manifested itself as
speedshop core dumping when using /dev/zero. The
fix for this problem was incorporated into patch
2294 which is now replaced by patch 2648, and also
requires patch 2397 (or its replacement).
Replaces and rolls up:
Patch 1820, which fixes bugs:
+o 426196: This was a bug in the specfs file system
that caused ioconfig and xlv_assemble to take a
very long time to run on systems with lots of
disks.
1.4 _S_u_b_s_y_s_t_e_m_s__I_n_c_l_u_d_e_d__i_n__P_a_t_c_h__S_G_0_0_0_2_8_3_5
This patch release includes these subsystems:
+o patchSG002835.eoe.sw.unix
1.5 _I_n_s_t_a_l_l_a_t_i_o_n__I_n_s_t_r_u_c_t_i_o_n_s
Because you want to install only the patches for problems
you have encountered, patch software is not installed by
default. After reading the descriptions of the bugs fixed
in this patch (see Section 1.3), determine the patches that
meet your specific needs.
If, after reading Sections 1.1 and 1.2 of these release
notes, you are unsure whether your hardware and software
meet the requirements for installing a particular patch, run
_i_n_s_t. The _i_n_s_t program does not allow you to install
patches that are incompatible with your hardware or
software.
- 4 -
Patch software is installed like any other Silicon Graphics
software product. Follow the instructions in your _S_o_f_t_w_a_r_e
_I_n_s_t_a_l_l_a_t_i_o_n _A_d_m_i_n_i_s_t_r_a_t_o_r'_s _G_u_i_d_e to bring up the miniroot
form of the software installation tools.
Follow these steps to select a patch for installation:
1. At the Inst> prompt, type
iiiinnnnssssttttaaaallllllll ppppaaaattttcccchhhhSSSSGGGG_x_x_x_x_x_x_x
where _x_x_x_x_x_x_x is the patch number.
2. Initiate the installation sequence. Type
IIIInnnnsssstttt>>>> ggggoooo
3. You may find that two patches have been marked as
incompatible. (The installation tools reject an
installation request if an incompatibility is
detected.) If this occurs, you must deselect one of
the patches.
IIIInnnnsssstttt>>>> kkkkeeeeeeeepppp ppppaaaattttcccchhhhSSSSGGGG_x_x_x_x_x_x_x
where _x_x_x_x_x_x_x is the patch number.
4. After completing the installation process, exit the
_i_n_s_t program by typing
IIIInnnnsssstttt>>>> qqqquuuuiiiitttt
1.6 _P_a_t_c_h__R_e_m_o_v_a_l__I_n_s_t_r_u_c_t_i_o_n_s
To remove a patch, use the _v_e_r_s_i_o_n_s _r_e_m_o_v_e command as you
would for any other software subsystem. The removal process
reinstates the original version of software unless you have
specifically removed the patch history from your system.
vvvveeeerrrrssssiiiioooonnnnssss rrrreeeemmmmoooovvvveeee ppppaaaattttcccchhhhSSSSGGGG_x_x_x_x_x_x_x
where _x_x_x_x_x_x_x is the patch number.
To keep a patch but increase your disk space, use the
_v_e_r_s_i_o_n_s _r_e_m_o_v_e_h_i_s_t command to remove the patch history.
vvvveeeerrrrssssiiiioooonnnnssss rrrreeeemmmmoooovvvveeeehhhhiiiisssstttt ppppaaaattttcccchhhhSSSSGGGG_x_x_x_x_x_x_x
- 5 -
where _x_x_x_x_x_x_x is the patch number.
1.7 _K_n_o_w_n__P_r_o_b_l_e_m_s